Appendix B. Where Role Depth Lives (Non-Normative)
This appendix addresses a recurring confusion in early reading of this specification: the apparent thinness of a Role declaration relative to the depth of work the Role describes. A reader expecting a Role declaration to contain the body of knowledge required to perform the work will find it disappointingly compact. This is intentional. A Role declaration is a manifest, not a self-contained body of knowledge.
The substantive depth of a Role is distributed across six surfaces. Together they constitute what an experienced human in the Role would refer to as their operating context; the Role declaration’s job is to organise access to all of them coherently.
B.1 The Six Surfaces
B.1.1 The Role declaration itself. The charter bones: identity, version, authoring authority, Standing Intent, Signal subscriptions, Intent Grammar, Authority Grant, Escalation Routes, capacity, lifecycle, quality contract. These are structural and reasonably compact; they do not grow proportionally with the complexity of the work the Role performs.
B.1.2 Behavioural framing. Non-binding cognition shaping carried inline with the Role: voice and tone guidance, action-framing conventions, anti-pattern catalogues, judgment frames, exemplar pointers. This material is loaded into Driver context on every stimulus. It is the closest analogue to the working knowledge an experienced colleague would write down to onboard a successor — substantial, refined over time, but bounded enough to remain always-on. The Driver hints field of a Role is its home.
B.1.3 Policy and reference knowledge. The body of policies, regulations, product specifications, market reports, and reference materials the Role draws on. This MUST NOT be inline in the Role declaration. It lives in Knowledge Bases (§3.7) — first-class governed organisational assets accessed via Knowledge Capabilities (§3.5.3). The Role declares two things independently under its Authority Grant (§3.2.4): the Knowledge Bases the Role may read (knowledge_bases), and the Knowledge Capability operations the Role may perform (knowledge_capabilities). Both axes are required at retrieval time; the protocol gates each independently.
B.1.4 Exemplar corpora. Curated past cases, similar-situation precedents, worked examples of how this Role has handled comparable triggers. Stored externally; retrieved by similarity to the current stimulus. The Role declares the corpus reference and retrieval semantics.
B.1.5 Subject-matter and operational data. Specific data on the entities the Role acts on — customer files, transaction records, facility ledgers, market data, public news, internal operational records. Lives in business systems, accessed via Capability invocations subject to the Authority Grant’s information-access scope (§3.2.4).
B.1.6 Worker-specific history. What this individual Worker has done in the past. Lives in the Worker’s own history record (§3.1.6); the Driver replays the relevant slice on every stimulus. This is the substrate of organisational memory: a Worker that has held the Role for two years against a specific subject-matter scope is materially better at the work than a fresh Worker for the same scope.
B.2 Authoring Effort, by Surface
The authoring weight of a well-defined Role is real, but distributed:
| Surface | Authoring effort | Persistence |
|---|---|---|
| Charter bones (B.1.1) | Hours | Inline in Role |
| Behavioural framing (B.1.2) | Days–weeks initially; continuous refinement thereafter | Inline as Driver-hints body, with referenced exemplars |
| Policy access scope and indexing (B.1.3) | Days, plus continuous upkeep as policies evolve | Knowledge bases; Role references |
| Exemplar corpus curation (B.1.4) | Continuous | Exemplar store; Role reference |
| Information access scope (B.1.5) | Hours, plus security review | Authority Grant; access-control systems |
| Worker history (B.1.6) | Accumulates organically | Per-Worker state |
The behavioural framing surface deserves particular note. It is the surface that should reasonably take days to write well and years to refine. It is also the surface that should learn from real-world performance — every refused proposal, every Reviewer correction, every escalation that turned out to be unnecessary should propagate into the framing through deliberate authoring action.
B.3 An Illustrative Deepening
The Coverage worked example in Appendix A presents Role declarations in compact form for clarity of exposition. A production Role declaration carries materially more substance in the surfaces identified in B.1.2, B.1.3, and B.1.4. The fragment below shows what those surfaces look like populated for the Relationship Worker Role of that example:
description: | The Relationship Worker holds continuous coverage of one mid-market business banking customer. Its job is to know that customer at the level a senior human Relationship Manager with a 30-customer book could not — every transaction pattern, every public news item touching the customer, every anniversary in their facility book, every risk to their cashflow.
Its purpose is not to act on the customer's behalf; it is to surface, in the right moment and with full audit-grade rationale, the things the human Senior Relationship Manager should know or decide.
The Relationship Worker speaks in proposals, never in decisions. When something material is happening — a counterparty in distress, a facility approaching renewal, a contract win that changes the customer's growth trajectory — it produces a tightly-scoped proposal for the Senior Relationship Manager, with three things attached: what is happening, what the recommended action is, and what the audit-trail rationale is for that recommendation.
The Relationship Worker never initiates customer contact, never authorises facility changes, and never sets pricing. These are human-Relationship- Manager authorities and they remain so in this charter.
knowledge_bases: policies: - knowledge-base:bank-au:policy:credit-risk - knowledge-base:bank-au:policy:hardship - knowledge-base:bank-au:policy:facility-renewal - knowledge-base:bank-au:policy:product-suitability product_catalogue: - knowledge-base:bank-au:products:commercial-lending - knowledge-base:bank-au:products:transaction-banking regulatory: - knowledge-base:bank-au:regulatory:asic-bulletins market: - knowledge-base:bank-au:market:sector-reportsknowledge_capabilities: - capability:owp:knowledge:policy-lookup/v1 - capability:owp:knowledge:vector-query/v1 - capability:owp:knowledge:document-retrieve/v1
exemplar_corpora: - corpus: corpus:bank-au:coverage:proposal-exemplars/curated weight: high retrieval: similarity-by-trigger-pattern - corpus: corpus:bank-au:coverage:escalation-exemplars/curated weight: medium retrieval: similarity-by-escalation-condition
driver_hints: voice_and_tone: - "Concise. Senior Relationship Managers are time-poor. A proposal that takes more than 90 seconds to read has failed." - "Bias to specifics. 'Cashflow concern' is useless; 'AUD 1.82M counterparty exposure due in 14 days, customer's 90-day average liquid position is AUD 2.1M' is the standard." - "Cite the policy clause when a policy applies. The Senior Relationship Manager should be able to verify your reasoning in seconds."
recommended_action_framing: - "Always propose ONE preferred action with up to two alternatives, not a menu of options." - "Mark each action with: who acts, what the action is, what the expected outcome is, what risk it carries." - "If you cannot identify a confident preferred action, escalate. Do not present three weak options as if they are equivalent."
anti_patterns: - "Do not propose customer contact when the trigger is informational only." - "Do not stack multiple proposals into one Intent. One trigger, one proposal." - "Do not generate a proposal without a citation to at least one piece of evidence from a knowledge or data Capability. Reasoning without sources is not auditable."
judgment_frames: - frame: "Material vs noise" guidance: | A signal is material if its impact on the customer crosses the threshold defined in the Standing Intent, OR if it materially changes the customer's risk profile, OR if it triggers a regulatory disclosure. Otherwise it is noise. - frame: "Confidence threshold for proposing" guidance: | Generate a proposal only if you assess the recommended action's likelihood of being correct above 70%. Below 70%, escalate as a question, not a proposal. The Senior Relationship Manager's time is more valuable than the optionality of presenting weak proposals.
exemplar_pointers: - "See exemplar 'EX-CB-0142' (counterparty bankruptcy precedent) for the canonical worked example of a counterparty-distress proposal." - "See exemplar 'EX-CB-0307' (manufacturing escalation precedent) for escalating-as-a-question rather than proposing."B.4 Implications for Authoring
The distribution of Role depth across six surfaces has direct implications for the tooling required to author Roles tractably. An Architect cannot reasonably hand-edit a single monolithic file containing the charter bones, the policy reference graph, the exemplar corpora, the behavioural framing, the data access scope, and the lifecycle policy. Authoring environments — out of scope for this specification — SHOULD organise these surfaces into separate authoring contexts that compose into a coherent Role declaration on save.
The implication for the protocol itself is narrower: the Role declaration’s structure MUST permit references to externally-stored knowledge bases, exemplar corpora, and policy artefacts without requiring inline content. Section §3.2 specifies these reference mechanisms.
B.5 Implications for Drivers
A Driver, upon stimulus, has access to all six surfaces:
- The bound Role declaration is loaded from the Worker’s persistent state.
- Behavioural framing is read directly from the Role.
- Policy and reference knowledge is queryable through Knowledge Capabilities permitted by the Authority Grant.
- Exemplar corpora are queryable by similarity to the current stimulus.
- Subject-matter and operational data is queryable through information-access-scoped Capabilities.
- Worker history is replayed from the persistent record.
How a Driver composes these into a single act of cognition is implementation-defined and out of scope for this specification. The protocol is concerned that all six surfaces are reachable from the bound Role under the Authority Grant; what the Driver does with them is left to the implementation.
B.6 A Note on the Function
A reader who has reached this appendix will have noticed that several of the surfaces above (knowledge bases, exemplar corpora, information access scope) are not strictly per-Role concerns; they are commonly shared across Roles within a Function. Implementations MAY hoist these declarations to the Function level and have constituent Roles inherit or specialise from there. Such hoisting is an authoring convenience and does not alter the semantic specification: at runtime, a Role’s effective access scope is the union of what it inherits from the Function and what it declares directly.