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.

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.

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