Appendix B. Where Worker Definition Depth Lives (Non-Normative)
This appendix addresses a recurring confusion in early reading of this specification: the apparent thinness of a Worker Definition declaration relative to the depth of work the Worker Definition describes. A reader expecting a Worker Definition declaration to contain the body of knowledge required to perform the work will find it disappointingly compact. This is intentional. A Worker Definition declaration is a manifest, not a self-contained body of knowledge.
The substantive depth of a Worker Definition is distributed across six surfaces. Together they constitute what an experienced human in the Worker Definition would refer to as their operating context; the Worker Definition declaration’s job is to organise access to all of them coherently.
B.1 The Six Surfaces
B.1.1 The Worker Definition 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 Worker Definition performs.
B.1.2 Behavioural framing. Non-binding cognition shaping carried inline with the Worker Definition: 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 Worker Definition is its home.
B.1.3 Policy and reference knowledge. The body of policies, regulations, product specifications, market reports, and reference materials the Worker Definition draws on. This MUST NOT be inline in the Worker Definition declaration. It lives in Semantic Memory (§3.7) — first-class governed organisational assets accessed via Memory Capabilities (§3.5.3). The Worker Definition declares two things independently under its Authority Grant (§3.2.4): the Memory items the Worker Definition may access (memory), and the Memory Capability operations the Worker Definition may perform (memory_capabilities). Both axes are required at access time; the protocol gates each independently.
B.1.4 Exemplar corpora. Curated past cases, similar-situation precedents, worked examples of how this Worker Definition has handled comparable triggers. Stored externally; retrieved by similarity to the current stimulus. The Worker Definition declares the corpus reference and retrieval semantics.
B.1.5 Subject-matter and operational data. Specific data on the entities the Worker Definition 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 Worker Definition 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 Worker Definition is real, but distributed:
| Surface | Authoring effort | Persistence |
|---|---|---|
| Charter bones (B.1.1) | Hours | Inline in Worker Definition |
| 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 | Semantic Memory; Worker Definition references |
| Exemplar corpus curation (B.1.4) | Continuous | Exemplar store; Worker Definition 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 Worker Definition declarations in compact form for clarity of exposition. A production Worker Definition 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 Definition 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.
memory: policies: - memory:bank-au:semantic:credit-risk - memory:bank-au:semantic:hardship - memory:bank-au:semantic:facility-renewal - memory:bank-au:semantic:product-suitability product_catalogue: - memory:bank-au:semantic:commercial-lending - memory:bank-au:semantic:transaction-banking regulatory: - memory:bank-au:semantic:asic-bulletins market: - memory:bank-au:semantic:sector-reportsmemory_capabilities: - capability:owp:memory:policy-lookup/v1 - capability:owp:memory:vector-query/v1 - capability:owp:memory: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 Worker Definition depth across six surfaces has direct implications for the tooling required to author Worker Definitions 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 Worker Definition declaration on save.
The implication for the protocol itself is narrower: the Worker Definition 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 Worker Definition declaration is loaded from the Worker’s persistent state.
- Behavioural framing is read directly from the Worker Definition.
- Policy and reference knowledge is queryable through Memory 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 Worker Definition 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-Worker Definition concerns; they are commonly shared across Worker Definitions within a Function. Implementations MAY hoist these declarations to the Function level and have constituent Worker Definitions inherit or specialise from there. Such hoisting is an authoring convenience and does not alter the semantic specification: at runtime, a Worker Definition’s effective access scope is the union of what it inherits from the Function and what it declares directly.