4. Roles

SENAR defines five responsibility sets. One person MAY cover multiple sets. Responsibilities SHALL be covered, not necessarily by dedicated positions.

For career paths, transition guides, and scaling ratios, see SENAR Guide and Reference.

4.1 Supervisor (SHALL — all configurations)

Directs AI agents, verifies output, makes architectural decisions, enforces Quality Gates.

Responsibilities: a) Define Tasks with goals and acceptance criteria before work; b) Provide structured context to the AI agent; c) Direct AI through execution with course corrections; d) Review all AI output against acceptance criteria; e) Make architectural and trade-off decisions; f) Enforce Quality Gates before closing Tasks; g) Capture knowledge entries during work; h) Maintain Session discipline (checkpoints, duration).

The production of engineering artifacts is AI-directed. A Supervisor who modifies an artifact directly supplies content by a route no QG-0 verdict covers — the verdict admits AI-directed production, and 8.6(j) states that the route is the origin of the content, not the identity of the process that writes the file. That is a Gate Bypass under 8.6(h) whether or not it was intended as one, and a positive QG-0 verdict for the Task does not cover it. Such a modification SHALL be recorded as a Gate Bypass, with the justification, risk acknowledgment, remediation plan, and senior approval that a Gate Bypass requires (Section 3.13).

Direct modification remains available and is expected to occur. As of this revision one case is recognized as substantive: an environment in which no agent can be run and there is nothing to switch to. Everything else the earlier list named — an agent stuck on a wrong approach, an agent that got most of the way, a fix cheaper than preparing context, a hotfix against a deadline — is addressable by agent means where an agent environment exists: a different model, a deeper pass, a second attempt. Where the environment is unavailable, those cases are the recognized one and not additional ones. What is not available in any case is doing it silently: the record is required for the recognized case as much as for any other, or metric 8 loses the population it is computed over (9.2). Cost of context preparation is a legitimate justification to record; it is not a reason to omit the record.

NOTE: The list above is dated. It states what agent capability makes addressable at the date of this revision, and the boundary moves as models change — which is why 10.13 requires re-evaluation of capability-dependent provisions when the model generation changes, and 0 marks such provisions as capability-dependent. A list of exceptions that is not re-read on that trigger describes the previous generation of tools within a year. Whether a case falls under the recognized one is decided by the senior who approves the Gate Bypass under 8.6(h); this Standard introduces no separate authority for it, and the single case is physical rather than organizational, so it does not scale by configuration.

4.2 Context Architect (SHALL — all configurations)

Designs requirements as structured AI input, manages the requirement hierarchy (BR → SR → TR), and ensures traceability. Quality is built at input: a defect in a Business Requirement cascades to all downstream System Requirements, Task Requirements, and ultimately to code. The Context Architect is the primary guardian of input quality.

Foundation (combined with Supervisor — Section 4.8, Section 11.1): At Foundation, the Supervisor absorbs Context Architect responsibilities. Minimum Foundation-level duties: a) Maintain the project context file (e.g., CLAUDE.md) and ensure it reflects current project state; b) Ensure context quality before task start — verify that QG-0 inputs are sufficient and well-structured; c) Design initial task decomposition (BR → TR at minimum).

Team (SHALL — dedicated): a) Maintain the requirement hierarchy (BR → SR → TR) with bidirectional traceability; b) Manage requirement lifecycle: draft → approved → verified → deprecated; c) Ensure requirement quality properties: verifiability (SHALL), consistency, sufficiency, non-redundancy, traceability [Team+: SHALL]; d) Prioritize work using WSJF (Section 3.29); e) Conduct periodic traceability audits to identify orphaned requirements (requirements without Tasks) and orphaned Tasks (Tasks without requirements); f) Enable requirement reuse by maintaining verified requirements as reusable Knowledge Base entries; g) Design Agent Profiles and manage Operational Scripts (Section 5); h) Review script changes as production process changes (Section 10.14); i) Maintain tool inventory per Agent Profile (Section 5.4).

4.3 Knowledge Engineer (SHALL Team+)

Captures, curates, and maintains the organizational knowledge base.

NOTE: At Foundation configuration, Knowledge Engineer responsibilities are combined with the Verification Engineer role and covered by one person (Section 4.8, Section 11.1). The “Team+” designation means a dedicated role; at Foundation, combined coverage applies. From Team, 4.8 sets whether the Knowledge Engineer is dedicated or shared across Pairs; from 5 Pairs the role is dedicated.

Responsibilities: a) Capture Dead Ends, decisions, patterns, known issues; b) Ensure entries are searchable and categorized; c) Review knowledge freshness; deprecate outdated entries; d) Analyze knowledge gaps.

4.4 Flow Manager (SHALL Team+)

Manages Session rhythm, cost tracking, and flow metrics.

NOTE: At Foundation configuration, Flow Manager responsibilities are absorbed by the Supervisor (Section 4.8, Section 11.1). The “Team+” designation means a dedicated role; at Foundation, combined coverage applies.

Responsibilities: a) Monitor Session duration and checkpoint cadence; b) Track cost per Task and Increment against budget; c) Monitor flow metrics (Section 9); d) Facilitate Increment Planning and Retrospective; e) Coordinate dependencies between Pairs (Federation); f) Schedule Quality Sweeps.

At Enterprise scale, expands to coordinate multiple Pairs (Federation Coordinator).

4.5 Verification Engineer (SHALL Team+)

Audits AI-generated output for correctness, security, and architectural conformance.

NOTE: At Foundation configuration, Verification Engineer responsibilities are combined with the Knowledge Engineer role and covered by one person (Section 4.8, Section 11.1). The “Team+” designation means a dedicated role; at Foundation, combined coverage applies.

Responsibilities: a) Conduct Quality Sweeps; b) Audit AI output using the AI Output Review Checklist (see SENAR Guide); c) Review AI-generated tests for coverage and assertion quality; d) Track Defect Escape Rate and identify systemic issues.

4.6 Enterprise Roles (Enterprise configuration only)

At Enterprise scale (10+ Pairs), three additional responsibility sets emerge:

Portfolio Manager: Coordinates multiple Increments across value streams. Manages unified budget, cross-stream dependencies, and strategic prioritization. Ensures AI investment aligns with organizational objectives.

Chief Supervisor: Sets architectural standards across all Pairs. Reviews and approves architectural exceptions. Defines organization-wide AI interaction patterns and context templates. Note: Chief Supervisor defines organization-wide standards; Context Architect (Section 4.2) implements them within specific projects.

Federation Coordinator: Manages cross-project dependency tracking, shared knowledge base governance, and cross-team requirement traceability. Facilitates Federation Sync ceremonies (Section 7.5) at the portfolio level.

These are responsibility sets, not job titles. One person MAY cover multiple Enterprise roles.

4.7 Summary

NOTE: This table states Team and Enterprise. What Foundation owes is stated in 11.1, and the headcount that covers it in 4.8; neither is repeated here. For entry-level adoption — one Pair, which is what 11.4 gives Core — see SENAR Core, where the Supervisor role absorbs all responsibilities.

4.8 Role Combinations by Team Size

NOTE: Role combinations are SHOULD-level guidance. Organizations MAY choose different combinations based on team skills and domain. The requirement is that all responsibilities are covered, not that specific combinations are used. This table is where headcount inside a configuration is set: the Responsibilities row of 11.2 states coverage and defers the number of distinct role-holders to the rows above.