Work Record Types & Identity (Fleet) v0.1

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:

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

Kind registry (closed list)

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)

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.

Flavor (bucket, not kind)

Flavor is a closed list on workplan and task, orthogonal to kind and to lifecycle status. It says what kind of demand this is, not whether it is open.

Unset flavor is not residual. Historic records without flavor: stay relevant until backfill classifies them (CUST-WP-0072). Do not auto-classify.

Unknown flavor values fail closed (rejected on write; consistency WARN).

Residuals (flavor, plus provenance role)

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.

On workplans and tasks the live classification is flavor: residual. origin: residual (or handoff) on intakes and promoted children remains provenance, not the default-view switch.

Default views omit residuals. State Hub open-workplan lists (/state/summary open_workplans, /state/next_steps, /state/deps, dashboard open widgets) and agent “should we implement this?” do not consider flavor: residual unless an explicit include is set (include_residuals=true or flavor=residual). Residuals are not equal open demand. Totals still report residual_open so the count cannot hide.

Promotion is a first-class transition: flavor: residual → planning | implementation | refactoring | extension when demand or risk meets the leftover. Record flavor_promotion_reason: demand | risk and optional flavor_promoted_from: residual in the file, then fix-consistency. After promotion the record is no longer residual and re-enters the default view.

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 with flavor: residual). 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: filter flavor: residual on workplans/tasks and intakes with origin ∈ {residual, handoff} via State Hub (GET /workplans/?flavor=residual, GET /state/summary?include_residuals=true). Implementation home is state-hub, not domain-local residual files.

depends_on (workplan frontmatter)

Workplan frontmatter depends_on is the canonical list of workplan ids this plan waits on. State Hub indexes those edges (C-20). Legacy keys depends_on_workplans and depends_on_tasks remain aliases until a legacy-meter retires them. Task-block depends_on continues to name sibling tasks; it is not a substitute for workplan-level edges.

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

Historical Custodian identifier compatibility (2026-09-09)

Preserve the source-bound suffix workplans CUST-WP-0000b, CUST-WP-0000c, CUST-WP-0010b, and archived CUST-WP-0017-LEGACY / CUST-WP-0053-LEGACY. The machine registry enumerates the observed suffixed task IDs and the 38 parent-local aliases in CUST-WP-0006, CUST-WP-0007, CUST-WP-0030 and CUST-WP-0031. These local aliases require an existing managed UUID and are collision-checked within their recorded parent. Qualified task IDs remain globally checked. Unknown aliases and missing historical bindings refuse ordinary registration; new tasks must use the canonical qualified convention. Compatibility does not rename source records, replace existing UUIDs, reactivate finished work or retire duplicate projection rows. The broader historical reconciliation remains CUST-IN-0017; validation evidence is in the 2026-09-09 assessment.