Choose responsibilities and execution resources

Chirality has four standing roles. A role describes a contribution, a workflow describes a method, a brief describes this assignment, and the host supplies actual capabilities. Do not create an expanded permanent roster merely because the work has many specialties. Put the specialty in the bounded assignment and its context. Root entry · Role registry

Role	Type	Use it for	Required relationship
HELP_HUMAN	0	Alignment, continuity, cross-undertaking coordination, and preparing consequential choices with the human.	Coordinates managers and may directly dispatch a bounded Type 2 contribution.
HELPS_HUMANS	1	Conceiving and designing projects, workflows, tools, and their boundaries.	Returns a sufficiently understood design and open questions for implementation; may delegate bounded execution.
WORKING_ITEMS	1	Organizing implementation, assigning bounded work, checking interfaces, and integrating the undertaking.	Owns the combined result; returns design-changing findings through the human or HELP_HUMAN.
TASK	2	One bounded contribution under its brief and selected method, if any.	Returns work, evidence, and coordination needs to its caller; does not delegate.

Read the active role instruction, not every role body on routine entry. Wider consultation is appropriate for comparison or coordination when needed, with origins and hashes recorded in governed evidence. A fresh named child receives the intended full role and its bounded brief. A full-history fork preserves context; it does not by itself establish a different role or a fresh independent reviewer. Root entry · Runtime contract

The registry gives HELP_HUMAN a read-only managed ceiling: read, delegate_agent, and send_agent_update, with write_scope: none. Its responsibility for continuity does not authorize direct file edits. Route graph maintenance, decision transcription, and other writes to an authorized recorder or manager with exact targets. A manager's own ceiling also does not grant unrestricted writes; its brief must supply them. Role registry · Runtime contract, structured brief compatibility

Native delegation needs equally accurate description. D-GOV-35 distinguishes Chirality-managed delegate_agent sessions from delegated-harness-native descendants. Native descent alone assigns no Chirality role, proves no non-delegation enforcement, and creates no acceptance authority. If the native host exposes broad tools while role and brief restrictions are instruction-asserted, report that fact. Never describe the host as mechanically enforcing a restriction merely because the agent followed it. Conversely, broad filesystem capability is not permission to exceed the assignment. D-GOV-35 · Root entry

Choose the arrangement around coordination needs. A small read-only comparison may go directly from HELP_HUMAN to TASK. An undertaking with implementation, evolving inputs, repairs, review, and integration usually benefits from WORKING_ITEMS. Several independent scopes can share a manager; a problem spanning Packages can require one coherent undertaking. A Package does not automatically require its own manager, nor does a graph node require a separate agent. HELP_HUMAN · WORKING_ITEMS · App project instructions

Model and reasoning settings are separate from role and Type. A difficult bounded review can require more capability than routine coordination. Consider the question, context, uncertainty, consequences, available checks, and total effort through repair and integration. Follow the current project convention and per-run steering; record actual model identity only when exposed by the host. App and Piping retain model allocation in run strategy and evidence, while PEC retains a distinct historical model convention that must be read in its own instructions. No role number is a capability ranking. App execution attribution · Piping execution attribution · PEC session convention