Ratified by founder 2026-07-20 (CUST-WP-0060-T01, hub decision f4640f9e). Source: `research/WorkOrchestrationArchitectureDraft.md` v0.2 (founder-reviewed 2026-07-20). Extends — does not replace — `workplan-terminology-fleet_v0.1.md` and ADR-001/ADR-005.

## Purpose

Define work record as the umbrella term for every identified, lifecycle-bearing coordination artefact in the fleet; register the closed list of work-record kinds, their id schemes and abstract lifecycles; and fix the two-layer identity rule. This is the backbone convention for all work — planning, development, testing, operations, security & compliance, controlling, billing, marketing, sales — under one conceptual framework (different demands are met by flow profiles and kind-specific fields, never by parallel ontologies).

## Core definition

A work record is any identified, lifecycle-bearing coordination artefact. A task is one kind of work record — the smallest executable unit. Every work record, regardless of kind, carries the conventional spine:

Field | Convention
--- | ---
`id` | canonical name per the type registry below
`uuid` | UUIDv7, hub-assigned at first index, written back to the source file
`kind` | one of the registered kinds
`lane` | autonomy lane (`autonomy-lanes_v0.1.md`)
`status` | abstract lifecycle of the kind (below)
`owner` | agent identity (`agt-…`) or human
`repo` | owning repo (ADR-001/ADR-005 anchor)
`tags` | policy + derived tags (§ Tags)
`created` / `updated` | dates (UUIDv7 supplies fine-grained internal time)

Kind-specific fields (budget, evidence, counterparty, deadline_pressure, attention_cost, …) extend the spine; they never replace it.

## Kind registry (closed list)

Kind | Id scheme | Meaning | Absorbs / legacy
--- | --- | --- | ---
`workplan` | `{PREFIX}-WP-NNNN` · `{PREFIX}-WP-ADHOC-YYYY-MM-DD` | structured, dependency-bearing body of work; repository-qualified daily container for small same-day tasks | unqualified `ADHOC-YYYY-MM-DD`; `MASON-0001` (grandfathered)
`task` | `{WP-ID}-TNN` | smallest executable unit | unqualified `ADHOC-YYYY-MM-DD-TNN`; `MASON-0001-TNN` (grandfathered); issue-core issues become external projections only
`intake` | `{PREFIX}-IN-NNNN` | spark: idea, finding, directive, request | hub suggestions (legacy, read-only close-out); `AWQ-NNN` (grandfathered)
`decision` | `{PREFIX}-DEC-YYYY-NNN` | approval package + resolution | `DEC-YYYY-NNN` (binky, grandfathered as-is)
`engagement` | `{PREFIX}-ENG-YYYY-NNN` | scheduled external interaction (counterparty, prepared material, time window) | `OH-YYYY-NNN` (grandfathered)
`register-entry` | existing schemes: `RISK-NNN`, `RISK-F-NNNN`, `RISK-REG-NNNN`, `TD-…`, `CAP-…`, `CCR-YYYY-NNNN`, `ADR-NNN` | risks/findings, regulatory records, technical debt, capability requests, credential change requests, architecture decisions | unchanged semantics, brought under the spine

Rules:

1. Prefix grammar: `{PREFIX}` is one or more uppercase alphanumeric segments, each beginning with a letter, joined by hyphens. Both compact prefixes such as `CUST` and repository-derived prefixes such as `RAPP-OPENBAO` or `RAIL-K8S` are canonical. The final `-WP-` token remains the unambiguous kind separator.
2. The registry is closed. An id pattern not registered in `work-record-types.yaml` fails CI and `fix-consistency` (the sidetrack detector). New kinds/prefixes are added by canon PR — deliberately cheap (one YAML entry + one schema) so the legitimate path is easier than any workaround.
3. Grandfathering: existing ids are never renamed. Legacy prefixes map to kinds in the registry; retirement of a scheme (never of records) follows the legacy-meter discipline of `workplan-terminology-fleet_v0.1.md`.

Compatibility correction 2026-08-23: State Hub message `24504ce7-4f73-47da-a150-629b07b37073` exposed that the machine pattern did not accept the already owner-registered `RAPP-OPENBAO-WP` prefix. The grammar now matches ADR-007's repository-derived prefix model; prefix ownership and uniqueness remain separate registry checks and are not weakened by this syntax correction.

The same compatibility review initially registered unqualified `ADHOC-YYYY-MM-DD` containers. A same-day collision between Activity Core and Net Kingdom then demonstrated that this form violates ADR-007's fleet-namespace uniqueness rule and cannot be used with deterministic UUID derivation. New daily records therefore use `{PREFIX}-WP-ADHOC-YYYY-MM-DD`; the filename remains `workplans/ADHOC-YYYY-MM-DD.md`. Existing unqualified ids are grandfathered and are never silently re-derived or disambiguated. Ad-hoc containers remain only for low-risk work completed directly.

Risk Nexus findings (`RISK-F-*`) and regulatory records (`RISK-REG-*`) are registered as variants of `register-entry`, not as parallel work kinds. Their lifecycles remain owned by the register convention. `RISK-N-*` notes are deliberately not registered: a note has no lifecycle, so it does not meet the core definition of a work record. A note becomes part of the backbone only when an event promotes its substance into a lifecycle-bearing kind.

## Identity layering

- UUIDv7 is primary for bookkeeping, relations, dependencies, and history. It is stable across renames, migrations, and terminology transitions.
- Canonical names are primary for humans and agents — UI, CLI, API output, prose, commits. UUIDs stay inspectable on demand but are never required reading.
- The hub writes the UUID back into the source file at first index (pattern: today's `state_hub_*_id` fields).
- A repeated source block with the same canonical id and the same UUID is one record with duplicate source occurrences. Index it once, retain every source location as diagnostic provenance, and report the duplication for governed cleanup. The repetition must not mint a second record. The same canonical id with different UUIDs is an identity collision and fails closed.

## Abstract lifecycles (canon-fixed, minimal)

Kind | Lifecycle
--- | ---
task | `wait → todo → progress → done \ | cancel` (InfoTechCanon)
workplan | `proposed → ready → active → blocked → backlog → finished → archived`
intake | `open → vetted → routed → closed(promoted \ | declined \ | absorbed)`
decision | `prepared → resolved(approved \ | rejected \ | revised \ | deferred)`
engagement | `queued → prepared → done`
register-entry | per existing register conventions (unchanged)

Promotion is a first-class transition: `intake.routed → workplan | task | decision | engagement`, executed by one CLI/MCP call that writes both artefacts, sets `promoted_to` / `origin` back-links, and re-syncs. Manual transcription of an intake item into other kinds is a process defect.

Kind-specific rigor lives in flow profiles, not extra states: named task-flow-engine workstation definitions whose entry/exit assertions encode per-work-kind gates (e.g. compliance tasks cannot exit `progress` without an evidence link). Profiles are YAML in repos, in the same reconciliation loop.

## Residuals (role, not kind)

A residual is work intentionally left after a workplan (or large task bundle) finishes. It is not a registered kind — inventing a parallel “residuals queue” or parking leftovers only in `SCOPE.md` / finished-file prose is a process defect. Residuals must be live work records so the hub can list them across repos and domains.

Residual shape | Capture as | Required links
--- | --- | ---
Small Green/Blue follow-up, parkable | intake (e.g. AWQ / `*-IN-*`) | `origin: residual`, `origin_ref: <parent-WP-id>`
Multi-step / dependency-bearing | workplan (spawn next WP) | body or frontmatter names parent WP; optional `origin`/`origin_ref` when promoted from intake
Needs founder choice | decision | same origin fields when created from residual intake
Needs founder time window | engagement | same
Persistent gap / risk | register-entry (risk, tech debt, …) | cross-link parent WP in notes

Close discipline for finished workplans:

1. Short residual narrative may remain under the closing task (human context).
2. Before `status: finished`, each residual that is still actionable becomes a live record (intake and/or child workplan). Prose alone is not the backlog.
3. Progress milestone may name the handoff ids.
4. `statehub fix-consistency` so the index (`WORK-RECORDS.md`, hub) reflects the handoff.

Fleet list (future CLI): filter open/vetted/routed intakes (and ready/ active workplans) with `origin ∈ {residual, handoff}` and optional `topic_id` / `repo` / `origin_ref`. Implementation home for that query is state-hub (`statehub residuals` / API), not domain repos.

## Source files, index, and views

1. Any repo file is a potential source of work records. Records are authored as schema-valid YAML blocks in context — thematic live documents, meeting notes, design docs, triage logs. The schema is the contract, not the location. Workplans keep dedicated files.
2. A generated per-repo work-record index references every registered record in its source location (transclusion-style; markitect-family tooling). It is the "everything across all files" orientation view and a concurrency cross-check.
3. Every working list is a generated view (`[auto]`-marked) over indexed records — autopilot views, decision queues, engagement batches, briefs. Hand-maintained completed-logs and queue tails are retired.
4. Ordering of views is lane + priority + age by default; dependency capture optional; WSJF optional and situational (overload triage only).

## Tags

Two classes, both in `tags`, never in `status`:

- Derived tags — computed, read-only in files: `stalled`, `stale`, `overdue-decision`, `budget-breached`, `orphaned`.
- Policy tags — assigned under tagging policies: `automatable`, `needs-human`, `unclear-implementation`, `red-adjacent`, `compliance-relevant`, `residual` (optional badge when origin is not used).

States migrate badly; tags migrate trivially. Anything situational is a tag.

Origin values (intake and promoted children): use stable strings, not free prose. For residuals prefer `origin: residual` (or `handoff`) and `origin_ref: <parent canonical id>` (e.g. `BINKY-WP-0006`). Other established origins (e.g. `legacy-suggestion:<uuid>`, mail-triage ids) remain valid.

## Budgets

Guardrail envelopes resolve programmatically at run start: workplan-frontmatter override → per-repo `budgets.yaml` (lane/default envelopes) → global best-guess default. Nothing runs unbounded. Budget resolution and enforcement is automation infrastructure, never agentic effort; metering via token events; breach ⇒ `budget-breached` + escalation.

## Reconciliation loop (normative)

    author (any repo file) → CI schema validation → commit
          → fix-consistency: register/sync, UUID write-back
          → hub read model → generated index + views → NATS events → activity-core

The hub remains a read model per ADR-001; runtime operations data (logs, metrics, run histories, token events) is the sanctioned DB-only exception.

## References

- `research/WorkOrchestrationArchitectureDraft.md` (v0.2)
- `research/2026-07-19-work-orchestration-infrastructure-survey.md`
- `research/2026-07-19-work-orchestration-best-practices.md`
- `canon/architecture/adr-001-workplans-as-repo-artefacts.md`, `adr-005-…`
- `canon/standards/workplan-terminology-fleet_v0.1.md`
- `canon/standards/autonomy-lanes_v0.1.md`
- `state-hub/docs/task-flow-engine-spec.md`