teams.sgit.ai / role-format

The ROLE.md format

Five fields make up a role's identity, and they appear — in one markup or the other — across 31 of the 39 ROLE.md files on disk. Measured 7 September 2026, from a full clone of the estate's own repositories.

This page describes the schema. For the drift between its two markup dialects, and the four directories with no file at all, see format drift, quantified →. For a role's own projection of this schema, every entry in the roster is one.

The schema

Field	What it does	Why it matters
Name	The role's handle	How other roles address it in comms
Location	`team/roles/<name>/`	The role's home for reviews and outputs
Core Mission	One sentence of purpose	The routing key — the Conductor reads this to assign work
Central Claim	The role's testable assertion	See below — the field that does the real work
Not Responsible For	The explicit exclusion list	See below — the field nobody else writes

Not Responsible For — the field that makes it a team

31 of 39 role files carry it. It is the most distinctive thing in the corpus and the reason a multi-role setup works at all.

writing code, running tests, deploying infrastructure, making architecture decisions, or performing security reviews
— Conductor, team/roles/conductor/ROLE.md

writing application code, making architecture decisions, running tests, deploying infrastructure, creating original specifications, or making product decisions
— Librarian, team/roles/librarian/ROLE.md

Why it matters more than the responsibility list: an LLM given a task will attempt it. Capability is not the constraint on a capable model — willingness is, and the exclusion list is the only thing that converts a capable generalist into a specialist that hands off. Without it, every role silently becomes the same role, and a "team" of nine agents is one agent invoked nine times.

A role without an exclusion list is not a role.

Central Claim — write it as a failure condition

This is the pack's most useful finding, and it is a regression the estate has not noticed.

The older bullet-list format states claims as falsifiable failures

If a piece of knowledge exists in this repo but cannot be found in under 30 seconds, the Librarian has failed.
— Librarian

If a dependency, data flow, or security boundary exists but is not visible on a map, the Cartographer has failed.
— Cartographer

If any code path exists where plaintext, decryption keys, or original file names could reach the server, AppSec has failed.
— AppSec

If a decision was made but its rationale is not recorded, the Historian has failed. The team will re-litigate it…
— Historian

If a potential user visits the site and cannot understand the zero-knowledge guarantee within 60 seconds, the Journalist has failed.
— Journalist

The newer table format states them descriptively

The Architect owns the boundaries. Every interface contract… passes through architectural review.
— Architect

The Conductor sees the full picture. No task starts without routing.
— Conductor

QA owns the test matrix… No release ships without QA sign-off.
— QA

The descriptive claims are true and useful. But you cannot check them. The failure-condition claims name a condition, a threshold and sometimes a time bound — thirty seconds, sixty seconds — which means an auditor, human or agent, can look for a counter-example and find one. That is the same falsifiability discipline that runs through risks.sgit.ai, wardley-maps.sgit.ai ("maps are claims") and threat-modeling.sgit.ai (the validated threat model), applied to organisational design.

Recommendation. Publish the failure-condition form as the canonical one, show the drift honestly, and treat a rewrite of the seven descriptive claims into testable form as an open build item — Q2 in the open-questions queue.

Section anatomy, by frequency

Measured across all 39 files:

Section	Files	Note
`## Identity`	37	The schema above
`## Tools and Access`	37	Where skills are named — skills.sgit.ai owns what they can do
`## For AI Agents`	37	The role speaking to its own occupant — see below
`## Quality Gates`	32	What must be true before the role signs off
`## Core Workflows`	25	The role's repeatable procedures
`## Primary Responsibilities`	19
`## Integration with Other Roles`	19	The routing table, per role
`## Measuring Effectiveness`	18	Asserted, not measured — G5
`## Escalation`	18	When to hand up rather than out
`## What You DO (Villager Mode)`	17	Topology-specific mandate
`## What You Do NOT Do`	15	The prose form of the exclusion list
`## Incident Response`	12

## For AI Agents in 37 of 39 files is the quiet innovation. These documents are written for a non-human occupant and say so in a dedicated section. That is the difference between an org chart and an agent brief, and it is the section a reader building their own team should copy first.