The GOVENANT Standard — Part 2: The Role Contract

An LLM is not an agent. A governed agent is a role with six configurable dimensions:

Agent = Occupant + Charter + Prompt + Skills + Tools + Context + Schedule

(Occupant is the seventh element but is not a behavioral dimension — it is who executes the other six.) Every dimension MUST be data: versioned, provenance-stamped, per-scope overridable, human-lockable, and visible in one UI surface. A dimension that lives in code is a dimension the organization cannot govern.

2.1 The six dimensions

Dimension	Definition	Must be	Enforcement point
Charter	Authority: levers owned, levers requestable, data consumed.	Data; single-ownership enforced at every actuation surface.	Ownership gate (Part 1 §1.3).
Prompt	Persona + behavioral instructions — how the role thinks and speaks.	Data; append-only versions with `changed_by`, `change_source`, `parent_version`; rollback; approval-gated changes.	Prompt resolution at run start (scope walk).
Skills	Reusable procedures/SOPs/playbooks the role knows how to run (“adversarial review,” “cold-outreach qualification,” “incident postmortem”).	Data; versioned like prompts; per-scope addable.	Prompt-injected only when held.
Tools	The concrete side-effecting handlers the role may call — the actuation path.	Data; scoped by role + scope; every write-tool re-guards ownership inside its handler.	Runtime grants only the tools in the matrix; an ungranted tool returns a structural refusal (`"not available here"`), not a polite decline.
Context	The knowledge sources the role reads before acting: KB categories, graph slices, documents, prior decisions.	Data; per-role bindings; auditable.	Context bindings scope what retrieval returns.
Schedule	The role’s duty roster: what it does, on what beat, producing what outcome (Part 3).	Data; versioned; human-approvable; diffed against reality daily.	Dispatcher generates work from duties; coverage audit diffs plan vs. actual.

The enforcement rule (non-negotiable, Law 1): the tool-calling runtime grants only what the matrix grants. Skills inject only when held. Context bindings bound retrieval. Duties bound the calendar. This — not the model — is what turns an LLM into a governed agent.

2.2 The storage pattern — one template, six instances

The Prompt Registry is the template the other five dimensions copy. It solves, once, every hard problem the others share:

Versioning: append-only version rows; never update in place.
Provenance: source ∈ {default, agent, human} (+ boardroom where deliberation commits); changed_by; parent_version.
Precedence: project > tenant > platform > code fallback resolution walk.
Locks: a human edit locks the key against agent overwrite (Part 8).
Rollback: restoring an old version is a new version with change_source='rollback'.
Approval-gated proposals: an agent proposing a change to its own configuration files a proposal through the normal approval tiers — self-modification is governed, not free.
Drift detection: the UI badges runtime-in-use vs latest-synced.

Do not invent six storage mechanisms. Reuse this one.

2.3 Portable schema

-- The role registry: every dimension of an occupant swappable by config.
CREATE TABLE roles (
  id TEXT PRIMARY KEY,
  scope_kind TEXT NOT NULL DEFAULT 'platform',   -- platform | tenant | project
  scope_id TEXT,                                  -- NULL = platform default
  role_key TEXT NOT NULL,                         -- 'cmo', 'senior_architect'
  title TEXT NOT NULL,
  persona_ref TEXT,                               -- prompt-registry key
  model TEXT,                                     -- occupant choice: model tier or 'human' or 'fn:<name>'
  owns_levers TEXT,                               -- JSON array — the charter
  can_request TEXT,                               -- JSON array
  reports_to TEXT,                                -- role_key of superior (org chart renders from this)
  feature_flag TEXT,
  source TEXT NOT NULL DEFAULT 'default',         -- default | agent | human
  created_by TEXT, created_at TEXT,
  UNIQUE(scope_kind, scope_id, role_key)
);

-- Skills: reusable procedures. Versioned like prompts.
CREATE TABLE agent_skills (
  id TEXT PRIMARY KEY,
  scope_kind TEXT NOT NULL DEFAULT 'platform', scope_id TEXT,
  key TEXT NOT NULL,                              -- 'adversarial_review'
  title TEXT, body TEXT,                          -- the SOP (prompt-injected when held)
  version INTEGER NOT NULL DEFAULT 1,
  source TEXT NOT NULL DEFAULT 'default',
  updated_by TEXT, updated_at TEXT
);

-- The grant matrix: which skills / tools / context each role holds.
CREATE TABLE agent_capabilities (
  id TEXT PRIMARY KEY,
  scope_kind TEXT NOT NULL DEFAULT 'platform', scope_id TEXT,
  role_key TEXT NOT NULL,
  kind TEXT NOT NULL CHECK (kind IN ('skill','tool','context')),
  ref TEXT NOT NULL,                              -- skill.key | tool.name | kb.category
  granted_by TEXT, granted_at TEXT,
  source TEXT NOT NULL DEFAULT 'default',         -- human > agent > default precedence
  UNIQUE(scope_kind, scope_id, role_key, kind, ref)
);
-- Schedule lives in role_duties — see Part 3 / SCHEMA.sql.

2.4 Customer-defined roles

Roles-as-data means customers MUST be able to create roles, not just override shipped ones — every organization has its own way of doing things. A new role is a new row (title, persona, model, lever assignments, grants, duties), subject to the same constitution-plane precedence and approval tiers as any config write.

Guidance: prefer general senior roles (a Senior Architect) over per-technology experts (a “TypeScript expert”). The model supplies the specialty; the role supplies the authority and the accountability. A customer with deep domain expertise loads it as skills and context on a general role (e.g. 50 pages of vendor documentation bound as a context pack), not as a new hardcoded personality.

Naming and personification. Persona names — including human-personified ones (“Morgan”, “Riley”) — are tenant configuration: permitted, never required, and always subordinate to the functional role_key, which is the identity the substrate governs, audits, and traces by. The standard’s own thesis argues against attaching identity to the occupant (the occupant is replaceable; the chair is not the name on it), so no conforming implementation may depend on a personified name for any mechanism. Where a tenant elects personified names, customer-facing surfaces MUST respect the tenant’s AI-disclosure policy at every terminal edge — a human name never implies, and must never be used to imply, a human author (see the claims discipline, Part 13 §13.7).

2.5 Document-seeded context

A tenant starting from scratch MUST be able to upload its existing documentation — specs, RFPs, runbooks, decks, diagrams — and have it become the baseline context: extracted, categorized into the knowledge fabric, and bound to roles via context grants. “Feed the org your docs” is the first onboarding step (Part 13 §13.4); a board of work items and the initial duty rosters SHOULD be generatable from those same documents.

2.6 The Agent Configuration surface

One per-agent page, five tabs — Prompt / Skills / Tools / Context / Schedule — completing the role contract on one screen:

Granted/held items with provenance chips (default / agent / human) and human-lock affordance.
Per-scope override view (what platform says vs what this tenant/project overrides).
Version history + rollback on every tab (the prompt-registry UX, reused).
Usage stats against the record: for tools, last-used / call-count from the action ledger; for duties, the duty-delivery ratio. A grant never exercised and a duty never delivered are both visible here — configuration is compared to reality on the page where you edit it.

Audit hooks (see Part 9, P2): ask the runtime for an ungranted tool — refusal must be code; grant/revoke as human — the lock must hold against an agent write; diff what the UI shows vs what the runtime actually grants — drift is a finding.